home *** CD-ROM | disk | FTP | other *** search
/ Power CD / Power CD ATARI-Rechner Lieben.iso / UTILITY / MACTEXT / MACTEXT.TXT < prev    next >
Encoding:
Text File  |  1991-02-17  |  12.4 KB  |  210 lines
  1. Dokumentation zu dem Programm MACTEXT    (C) ONKISOFT 1999
  2.  
  3. Geschrieben von Gero Zahn
  4.                 Bergring 27
  5.                 4953 Petershagen
  6.                 Tel.: 05707/2501
  7.  
  8.                 KTO 57326548
  9.                 BLZ 49050105
  10.                 Sparkasse Minden Lübbecke
  11.  
  12. Welchen Aladin-Nutzer hat die Tatsache noch nie  gestört, daβ Texte, die
  13. mit MacWrite, Turbo-Pascal, Ragtime oder irgendeinem anderen Programm
  14. eingetippt worden sind, auf immer und ewig in der Hölle des
  15. Aladin-Formates verschwunden blieben. Des gleichen umgekehrt: Hat man
  16. unter MSDos in Turbo-Pascal etwas geschrieben, will man es (weil PCDitto
  17. ja eine lahme Ente ist) sicher unter einem schnelleren System laufen
  18. lassen. Was liegt da näher als Turbo-Pascal unter Aladin?
  19.  
  20. Von MSDos hin zum Mac gibt's eigentlich keine Probleme: Es gibt da ein
  21. Programm namens "Gem To Mac", das unter Aladin läuft. Normalerweise
  22. ausgeworfene Gem-Disketten behält er bei sich und (vorausgesetzt, die
  23. Diskette ist 80 Tracks/9 Sektoren formatiert) läβt sich jedes beliebige
  24. File in die leers Superdisk kopieren. Von dort aus kann das gleiche
  25. Programm die Files weiterkonvertieren, entweder als Text-Files
  26. (MacWrite-Format) oder als Bilder (MacPaint-Format). Somit kein Problem.
  27. Wer das Programm nicht hat, hat natürlich Probleme ...
  28.  
  29. Doch zurück: Man hat beispielsweise unter Ragtime einen Text geschrieben,
  30. sagen wir, eine Kurzgeschichte. Der Ausdruck ist ja ganz nett, doch
  31. andererseits wäre es schon ganz schön, das Ding unter Wordplus
  32. weitereditieren zu können, denn auf die Dauer hat man unter Atari-TOS doch
  33. mehr Möglichkeiten. Aladin ist in dieser Beziehung doch eine ziemliche
  34. Sackgasse. Auβerdem: Bis der Finder von Diskette hochgefahren ist, kann
  35. man getrost noch mal 'ne Tasse Kaffee trinken, während Wordplus nach ein
  36. paar Sekunden da ist.  "Was tun?" sprach Zeus.
  37.  
  38. Über eins sollten wir uns im Klaren sein: Die Schrift-Attribute werden den
  39. Weg eines vergänglichen gehen. Doch für Turbo-Pascal-Sourcetexte ist das
  40. ja nicht von Bedeutung. Bei Texten rollt schon die eine oder andere
  41. Krokodilsträne. Naja, was soll's.
  42. Als erstes speichern wir den Text als reines Textfile ab. MacWrite hat
  43. eine entsprechende Option. Exportiert man den Text unter RagTime, so hat
  44. man sofort ein reines Textfile, ebenso ist ein abgespeichertes Pascal-File
  45. schon so wie es soll. Nun steht man vor dem Problem: Wie bekomme ich
  46. dieses File ins Atari-Diskettenformat?
  47.  
  48. Ein Programm wie "Gem To Mac" existiert meineswissens bis jetzt noch
  49. nicht, aber ich arbeite dran. Wer sich dafür interessiert, soll sich mal
  50. bei mit melden.
  51. Bis dahin behelfen wir uns mit einer Notlösung: Wir kopieren das File auf
  52. eine frisch formatierte Diskette. Mit brauchbaren Diskettenmonitoren (PD
  53. gibt's die Dinger ja wie Sand am Meer) kann man per Such-Option leicht den
  54. Anfang und das Ende des Textes finden. Bei Pascal-Programmem sucht man am
  55. einfachsten "PROGRAM", das ja bekanntlich ganz am Anfang steht, und
  56. "END.", ditto am Ende. Brauchbare Monitoren lassen einem die Möglichkeit,
  57. den gesamten Bereich zwischen zwei Markierungen als Diskettenfile
  58. abzuspeichern, gegebenenfalls auf Ramdisk. Dadurch, daβ die Diskette
  59. frisch formatiert war, kann man beruhigt davon ausgehen, daβ das File
  60. zusammenhängend auf der Diskette steht. Somit hat man nun ein sauberes
  61. Mac-File vor sich. Wer über keinen Monitor mit diesen speziellen
  62. Fähigkeiten verfügt, soll sich entweder selbst einen schreiben oder sich
  63. bei mir melden, ich habe da ganz brauchbare Dinger.
  64.  
  65. Frisch ans Werk: Gleich eingeladen mit der erstbesten Texterarbeitung.
  66. Doch ins neun von zehn Fällen wird sich das als (man verzeihe mir den
  67. Ausdruck) der sprichwörtliche Griff in Klo herausstellen.
  68. Hat man mit MacWrite gearbeitet, hat man ja ein Flieβtext-File vor sich.
  69. Das Format ist wie folgt: Es gibt keine Zeilen-Einschnitte, nach jedem
  70. Absatz steht mal gerade ein "CR". Normale ST-Textverarbeitungs-Programme
  71. benötigen aber normalerweise nach jeder Zeile "CR/LF", und zum Beispiel
  72. Tempus 2.0 braucht hinter einem Absatz zusätzlich nochmal "CR". Auβerdem
  73. ist eine Zeile (daβ sie mit "CR" aufhört, verstehen die meisten Programme
  74. noch) entschieden länger als gewohnt. Bei Tempus 2.0 ist eine Zeile
  75. maximal 160 Zeichen lang. Ein ganzer Absatz hat aber (z. B. bei 10 Zeilen)
  76. schon etwa 800 Zeichen. Und was nun?
  77.  
  78. Bevor wir uns mit diesem Problem beschäftigen, reden wir besser erstmal
  79. von einem anderen: Der Miβerfolg mit dem Textverarbeitungsprogramm hat uns
  80. nicht im geringsten abgeschreckt. Schauen wir uns das Mac-Textfile erstmal
  81. direkt vom Desktop an. Also: Doppelclick und dann "Anzeigen".
  82. Komischerweise zeigen sich im Text die wildesten Grafik-Zeichen und/oder
  83. Buchstaben, wo normalerweise Umlaute, Vokale mit Akzenten oder andere
  84. Zeichen stehen sollten. Das liegt an folgender bösen Falle: Der Mac
  85. verfügt (wie die meisten normalen Computer) über einen ASCII-Zeichensatz,
  86. zumindest alle Zeichen bis einschlieβlich chr(127) stimmen exakt überein.
  87. Was dann folgt, ist ein planloses Tohuwabohu. Ein ST und ein PC verfügen
  88. (ungefähr zumindest) über einen USA-Zeichensatz. Der Mac hat da seine
  89. eigenen Konventionen. Faktisch ist es so, daβ fast jedes USA-ASCII-Zeichen
  90. auch im Mac-Zeichensatz vorkommt, nur an einer anderen Stelle. Was man nun
  91. bräuchte, wäre zuallererst mal ein Zeichenkonverter, ein Programm also,
  92. das weiβ, wo im ST-Zeichensatz jedes beliebige Mac-Zeichen steht. Stellen
  93. wir uns vor, wir hätten ein solches Programm. De facto verrichtet MACTEXT
  94. diese Aufgabe ohne Anstand.
  95.  
  96. Jetzt haben wir ein nettes ST-Textfile. Alle nicht implentierten Zeichen
  97. (wie zum Beispiel das angebissene Äpfelchen) wurden entfernt, ebenso
  98. automatische Trennungen, die RagTime produziert und desgleichen mehr. Was
  99. will der Mensch noch mehr?
  100. Noch immer stimmen die Zeilenende-Markierungen nicht. Daher hat MACTEXT
  101. des weiteren die Option, die Zeilenende-Kennungen gegen eigene
  102. auszutauschen. Man hat die Wahl zwischen "CR" (keine Änderung), "CR/LF"
  103. (Standard-Zeilenende) und "CR/CR/LF" (Tempus 2.0 Flieβtext). Wozu Punkt
  104. eins gut ist, weiβ ich selbst nicht so genau. Man kann's ja vielleicht mal
  105. brauchen. Für Pascal-Programme, die ja kein Flieβtext sind, reicht Punkt
  106. zwei völlig aus. Man kopiert das erhaltene File nur noch auf eine
  107. MSDos-Diskette und kann sofort mit Turbo-Pascal anfangen,
  108. herumzuexperimentieren. Ein paar kleine Änderungen in der Implementation
  109. sind sicher erforderlich, aber so grob isses das schon mal.
  110. Doch zu Flieβtext-Texten. Ich verfahre immer so: Als Zeilenende lasse ich
  111. mit "CR/CR/LF" einsetzen. Somit sind da, wo auch vorher welche waren, auch
  112. für Tempus 2.0 Absätze. Probleme gibt's nur mit den überlangen Zeilen. Es
  113. gibt da aber eine Möglichkeit: Ich benötige einen Tempus, der gleich beim
  114. Einladen eines Textes im Flieβtext-Modus steht. Tempus wird beim Einladen
  115. meckern, daβ ihm die Zeilen zu lang sind. Ganz logisch. Er wird fragen,
  116. was er mit den zu langen Zeilen machen soll: 1. Zeilenlänge anpassen.
  117. Dieser Punkt wird durchgestrichen sein, weil die Zeilenlänge sicher länger
  118. als die maximale ist; 2. Abbruch. Das können wir uns schenken - Dazu haben
  119. wir Tempus nicht gestartet; 3. Zeilen abschneiden. Das können wir uns auch
  120. sparen. Von jedem Absatz hätten wir nur die erste Zeile. Das ist also
  121. vollkommener Quatsch; 4. Zeilen abknicken. Das isses! Der Rest des
  122. Absatzes wird in die nächste Zeile gesteckt. Paβt das auch nicht, geht der
  123. Rest wieder in die nächste Zeile, und so weiter. Somit haben wir immerhin
  124. schon mal den gesamten Text im Speicher, wenn auch mit etwas merkwürdigen
  125. Trennungen an den Zeilenenden.
  126. Nun kommt wieder einmal ein kleiner Trick mit einem groβen Effekt: Wenn
  127. wir nun die angestrebte Zeilenlänge einstellen und den Menüpunkt "Text
  128. reformatieren aufrufen, werden die auseinandergeschnittenen Wörter wieder
  129. zusammengeklebt. Wieso das? Nun, es ist so, daβ Tempus (immer wenn er eine
  130. neue Zeile beginnt) das letzte Leerzeichen der letzten Zeile auch dort
  131. stehen läβt, als Wortende-Kennung eben. Daran erkennt er, daβ hier eine
  132. neue Zeile beginnt, wenn auch im Flieβtext. Beim "Zeilen abknicken" gab es
  133. keine Leerzeichen am Zeilenende. Die Zeile endete mit einem Buchstaben und
  134. einem "CR/LF". Beim neuerlichen formatieren fügt Tempus die Wörter wieder
  135. zusammen ohne ein Wort des Widerspruches. Die neuen Wörter kommen korrekt
  136. in den Blocksatz oder ins linksbündige Format. Das Wunder ist geschehen:
  137. Wie haben den ehemaligen Mac-Text im Tempus-Flieβtext-Format.
  138.  
  139. Doch wie ich mich kenne, kenne ich sicher auch andere Nutzer, die den Text
  140. gerne im Wordplus-Format hätten. Das kostet nun auch nicht mehr viel
  141. Arbeit: Das Wordplus-File-Format ist irgendwie recht komplex, also
  142. konvertieren wir den Text doch besser einfach nur in Wordplus-Blockformat.
  143. Dabei entfallen logischerweise das Seitenformat, das Linieal etc. etc. ...
  144. Wordplus benutzt als Leerzeichen-Substitute (also statt chr(32)) den
  145. ASCII-Code chr(30). Das ist auch der Grund, warum Wordplus-Texte bei
  146. direkten Anzeigen vom Desktop aus immer so komisch unleserlich sind. Ein
  147. direkter Grund dafür war mir nicht direkt deutlich. Feste Leerzeichen
  148. haben sind jedenfalls auch chr(32) ...
  149. Das Prinzip des Flieβtextes hat Wordplus ja auch, wenn auch nicht so schön
  150. wie Tempus. Die Erkennung der Absätze funktioniert aber etwas anders: Alle
  151. Zeilen enden mit "CR/LF". Eine Zeile, mit der nicht gleichzeitig der
  152. Absatz endet, hat ein Leerzeichen am Ende, bzw. ein chr(30).
  153. Wie ich bereits erwähnte, hat Tempus das auch, als Wortendekennung. Somit
  154. entspricht die Sache schon richtig gut den Konventionen. Als erstes müssem
  155. wir alle Leerzeichen durch Substituten ersetzen. Das ist mit der "Suchen &
  156. Ersetzen"-Option von Tempus eine Arbeit von einer Sekunde. Was jetzt noch
  157. stört, sind die überflüssigen "CR"'s am Ende der Absätze. Um die
  158. Wegzukriegen, schaltet man in den Quelltext-Modus und klickt den Menüpunkt
  159. "Zeichenredundanz" an. Dabei werden alle einzelnen "CR"'s rausgestrichen.
  160. Den so erhaltenen Text speichert man einfach als "nnn.BLK" ab. Mit
  161. Wordplus öffnet man einfach ein neues Dokument "mmm.DOC" und lädt
  162. "nnn.BLK" als Block ein. Durch neues formatieren des ganzen Textes wird
  163. der Text (in manchmal minutenlanger Arbeit) an das neue Lineal gewöhnt.
  164. Jetzt kann man anfangen, die verlorenen Text-Attribute mittels "Restyle"
  165. wieder einzubringen. Dann ist das nächste Wunder geschehen: Der Mac-Text
  166. ist via Direktmodus-Tempus-Hamburg-Hannover zu Wordplus gekommen. Man
  167. verlange jetzt nicht von mir, ihn wieder zurück zu bringen. Theoretisch
  168. möglich ist aber alles.
  169.  
  170. MACTEXT konvertiert also "nur" die Zeichen und die Zeilen-Enden. Von daher
  171. ist die Bedienung auch ziemlich einfach:
  172. Nach einer kleinen Begrüβungs-Box erscheint eine File-Selector-Box und die
  173. Meldung, das Mac-Text-File anzuklicken. Danach kommt eine zweite
  174. File-Selector-Box, die den Namen eines ST-Textfiles verlangt. Man fährt
  175. immer gut mit den Endungen ".MAC" und ".TXT". Je nach vorhandensein des
  176. Ziel-Files wird entsprechend reagiert. Es bedarf wohl keiner weiteren
  177. Beschreibung.
  178. Nun folgt noch die Frage nach der neuen Zeilenende-Kennung: Default ist
  179. "CR/CR/LF" (für Flieβtxte).
  180. Nun folgt ein Window, in dem das prozentuale Fortschreiten des Programms
  181. angezeigt wird. Es ist sicher nicht das schnellste, aber es funktioniert
  182. immerhin.
  183. Die nunfolgende Frage nach einem neuerlichen Programm-Lauf erklärt sich
  184. sicherlich von selbst.
  185.  
  186. Theoretisch war's das. Wer an dem Listing (vor allem interessant wegen der
  187. Konversions-Tabelle, die ich in ein durchwachten Nacht erstellt habe)
  188. interessiert ist, möge mir einfach schreiben. 10,- DM und eine formatierte
  189. und virenfreie Diskette sind dazu nötig. Updates gibt's unter den gleichen
  190. Bedingungen. Als Update wird wohl demnächst das komplette Paket "Mac To
  191. Gem" erscheinen, die Zeichen- und Zeilenende-Konversion inbegriffen, plus
  192. eine Routine, die das lästige Suchen nach File-Anfang und -Ende beendet.
  193. Das wird dann wohl auch auf vollen (also nicht unbedingt
  194. frisch-formatierten) Aladin-Disketten funktionieren. Also, Leute, haltet
  195. Euch ran!
  196.  
  197. Für Bug-Reports bin ich natürlich immer offen. Ein Bug liegt übrigens bei
  198. folgendem Sachverhalt nicht vor: Unter Aladin gibt es ein Zeichen,
  199. erreichbar über ALT-".", das aussieht wie drei Punkte hintereinander. Dies
  200. ist das einzige Zeichen, dem MACTEXT bei der Konversion eine ganze
  201. Zeichenkette (nämlich "...") zuordnet. Das ist durchaus so gewollt!
  202.  
  203. Für Spenden im 10,- -Bereich bin ich (also armer Schüler) natürlich auch
  204. immer offen ...
  205.  
  206. Tja, Leute, dann bis die Tage ...
  207.  
  208.                                 Gero Zahn, Petershagen, den 3.9.1989
  209.  
  210.